Наш подход к проектам

Жизненный цикл любого продукта состоит из трех стадий:

Стадия Discovery

Работа над любым проектом в Polygant начинается с этой обязательной стадии. Она занимает около 100 рабочих часов команды и стоит 7000 USD. В результате работы формируется комплект документации, описывающей будущее приложение:

• спецификация (ТЗ);
• мокапы экранов.

На основе этих документов мы подготавливаем оценку стоимости и сроков реализации проекта, после чего отправляем её на согласование. Как только оценка утверждена, мы переходим к следующему этапу — Delivery.

⚠️ Мы не оцениваем стоимость и сроки проектов без детальной спецификации, подготовленной нашими специалистами.

Стадия Delivery

Разработка продукта ведётся строго по согласованной спецификации. Процесс работы обычно разделён на 3–4 этапа, каждый из которых имеет чёткие показатели готовности. Оплата тоже может проводиться поэтапно.

Мы используем методологию Agile с разделением на спринты, продолжительность одного спринта — 2 недели. В течение каждого спринта обновляется рабочая версия проекта, а наши клиенты могут в режиме реального времени наблюдать за процессом разработки и прогрессом своего продукта.

Стадия Support

После того как продукт (или MVP) разработан и запущен, мы переходим к поддержке и доработке. Мы предлагаем платную поддержку и сопровождение всех проектов, созданных нашей командой, на неограниченный срок.

Принципы работы нашей команды

• Работаем с проектами трудоемкостью от 1000 часов. Не беремся за проекты меньшей трудоемкости.
• Стараемся не брать проекты, которые «должны быть готовы вчера», поскольку не можем работать в спешке.
• Всегда работаем после полной или частичной (не менее 50%) предоплаты.
• Не участвуем в тендерах и госзакупках.
• Не работаем с чужим кодом и legacy, кроме заказов рефакторинга.

Подробнее о стадии Discovery

Как хороший дом невозможно построить без проекта и чертежей, так и хорошее приложение невозможно разработать без детального описания.

Спецификация проекта (также известная как «техническое задание» или «дизайн-документ» в мобильных играх) — это то, с чего необходимо начинать разработку любого продукта, и это первое с чего начинаем мы.

⚠️ Без технического задания невозможно точно оценить стоимость и сроки разработки.

Мы начинаем с того, что формируем рабочую группу, в которую войдут:

• представитель заказчика;
• проектный менеджер;
• проектировщик UI;
• аналитик.

После этого мы согласовываем дату и время первичного звонка. В рамках первичного звонка мы выясняем как заказчик видит проект, его пожелания и проходимся по заранее подготовленным вопросам.

Документ готовится на платформе Google Docs, доступ к которому сразу предоставляется заказчику. Мокапы экранов готовятся в Figma. Таким образом, заказчик может в режиме реального времени следить за подготовкой документа, вносить в него коррективы и предложения.

⚠️ При необходимости в рабочую группу могут быть добавлены более узкие специалисты не только с технической, но и с юридической стороны.

Что такое спецификация

Спецификация (техническое задание) — это документ, который содержит детальное описание будущего продукта с различных сторон, концептуальной, стороны юзабилити и юзкейсов, технических требований.

В ТЗ, создаваемых специалистами нашей компании, мы зачастую включаем схемы экранов будущего приложения, что значительно упрощает восприятие.

Какие задачи решает спецификация

• Сроки и стоимость — важнейшее, что интересует заказчика. ТЗ позволяет детализировать проект, проработать все нюансы, от которых может в значительной степени зависеть стоимость и сроки проекта.
• Синхронизировать понимание проекта между заказчиком и исполнителем. Очень часто это понимание может сильно разниться и без проработанного ТЗ приводит к конфликтам.
• Определить пути решения сложных аспектов проекта.

Над спецификацией обычно работают специалисты с наивысшей квалификацией и опытом в различных областях, это позволяет им видеть оптимальные решения там, где другие не могут.

Из чего состоит спецификация (ТЗ)

У каждого технического задания своя структура, но в целом можно выделить 5 разделов:

1. Описание проекта. Простыми словами объяснение что за продукт или сервис разрабатывается, для чего нужен, как работает.
2. Структура компонентов. Какие компоненты будут в проекте: бэкенд, фронтенд, мобильные приложения, как они будут взаимодействовать.
3. Технологический стек. Какие языки разработки будут использоваться, технические требования к программному обеспечению.
4. Юзкейсы. Сценарии использования приложения пользователями. В этом разделе может быть также карта экранов и мокапы ключевых экранов.
5. Безопасность и отказоустойчивость. Каким образом будет реализовываться защита от взлома, а также устойчивость к нагрузкам и масштабирование.

В среднем техническое задание занимает 20–40 страниц A4.

В конце технического задания, которое выполняют специалисты нашей компании, мы предоставляем расчет стоимости и сроков выполнения проекта.

Подробнее о стадии Delivery

После того как заказчик примет оценку стоимости и сроков, проект разделится на этапы и поступит предоплата за первый этап, мы переходим к стадии Delivery.

В ранее созданную команду добавляются новые участники, как правило это:

• 2–3 бэкенд-разработчика (Python);
• 2–3 фронтенд-разработчика (JavaScript), если нужно веб-приложение;
• 2–3 Flutter-разработчика, если нужно мобильное приложение;
• DevOps;
• QA-инженер;
• дизайнер.

Могут быть добавлены дополнительные специалисты, например Solidity, в зависимости от ТЗ.

В составе команды из 10—14 человек происходит планомерная разработка продукта. Спринт за спринтом он все сильнее обретает контуры и степень готовности.

Если стадия Discovery пройдена правильно и не возникает дополнительных работ или изменений, то с большой вероятностью мы уложимся и в сроки, и в бюджет, что редко случается на рынке.

Подробнее о стадии Support

Когда основная часть разработки выполнена и MVP запущен, мы переходим в режим поддержки и доработок. Если доработок не очень много, мы обычно оставляем на проекте небольшую команду с частичным (25%) вовлечением:

• проектного менеджера;
• QA-инженера;
• бэкенд-разработчик;
• фронтенд- или Flutter-разработчика;
• DevOps.

Если планируется много доработок и новых функций, команда может быть расширена.

Также, если это предусмотрено контрактом, наши специалисты могут подготовить пользовательскую документацию и произвести обучение команды заказчика по использованию продукта.

Если по каким-то причинам заказчик отказывается от дальнейшей поддержки, после всех взаиморасчетов мы передаем исходный код и убираем команду с проекта, перенося ее на другие проекты.

В случае, если возникает запрос на внесение изменений в продукт, нам потребуется пересобрать команду. Это целесообразно только при масштабных доработках от 500 часов и больше.